home *** CD-ROM | disk | FTP | other *** search
/ TeX 1995 July / TeX CD-ROM July 1995 (Disc 1)(Walnut Creek)(1995).ISO / tex-k / tex-k-archive.past / tex-k-archive.gz / tex-k-archive / 000400_kb@cs.umb.edu_Wed Mar 16 00:43:47 1994.msg < prev    next >
Internet Message Format  |  1994-10-11  |  1KB
  1. Received: from terminus.cs.umb.edu by cs.umb.edu with SMTP id AA24930
  2.   (5.65c/IDA-1.4.4 for <tex-k-exp@cs.umb.edu>); Wed, 16 Mar 1994 05:43:49 -0500
  3. Received: by terminus.cs.umb.edu id AA27000
  4.   (5.65c/IDA-1.4.4 for tex-k); Wed, 16 Mar 1994 05:43:47 -0500
  5. Date: Wed, 16 Mar 1994 05:43:47 -0500
  6. From: "K. Berry" <kb@cs.umb.edu>
  7. Message-Id: <199403161043.AA27000@terminus.cs.umb.edu>
  8. To: tim@maths.tcd.ie, tex-k@cs.umb.edu
  9. Subject: Re: Kpathsearch -- database searching
  10.  
  11.     but I'd like to suggest that Karl might use
  12.     the standard db/ndb libraries,
  13.     rather than using home-grown db utilities.
  14.  
  15. I considered doing this, but rejected it.
  16.  
  17. [n]dbm is unacceptable, since its binary files are byte-order dependent.
  18.  
  19. db doesn't have that problem, but its input files are not readily made
  20. for this task. I'd have to write and distribute and maintain a special
  21. script to generate them.
  22.  
  23. Also, then people wanting to use the ls-R would have to obtain, compile,
  24. and install db. This is not a trivial task.
  25.  
  26. And they would have to generate the binary version of the db input file,
  27. and keep that up-to-date with the original.
  28.  
  29. All of this seemed far too complicated for our needs. My home-grown db
  30. ``utilities'' is really nothing but one 150-odd line file (db.c),
  31. including comments :-)